[tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
"Karl Stahl" <karl.stahl@intertex.se> Mon, 24 February 2014 23:03 UTC
Return-Path: <karl.stahl@intertex.se>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FFA1A030A; Mon, 24 Feb 2014 15:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.801
X-Spam-Level: *
X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp0hYZAXodU5; Mon, 24 Feb 2014 15:03:04 -0800 (PST)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 602201A01CB; Mon, 24 Feb 2014 15:03:03 -0800 (PST)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250002595903; Tue, 25 Feb 2014 00:02:59 +0100
From: Karl Stahl <karl.stahl@intertex.se>
To: "'Cullen Jennings (fluffy)'" <fluffy@cisco.com>, 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'Simon Perreault' <simon.perreault@viagenie.ca>, 'Ted Hardie' <ted.ietf@gmail.com>, 'Gonzalo Camarillo' <gonzalo.camarillo@ericsson.com>, rtcweb@ietf.org, tram@ietf.org
References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <CAKhHsXGzA=ZTFGTK7ht9hQbfG70iqKrDtxrZCdQNNMzBYZCk8A@mail.gmail.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <CAKhHsXGsp6ma6Ko9op+YFRqSGM_Ex-jFo_fjz69rN0SEHfNK2A@mail.gmail.com> <CALDtMrKb3_38Rs0vaGnpEvNvTYz8YUTo89STvLJNXfkfdipDSQ@mail.gmail.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <B7FA2629-6D48-4569-BB62-56395C3EE4BC@cisco.com>
In-Reply-To: <B7FA2629-6D48-4569-BB62-56395C3EE4BC@cisco.com>
Date: Tue, 25 Feb 2014 00:02:57 +0100
Message-ID: <04ff01cf31b4$8eb73780$ac25a680$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0500_01CF31BC.F07B9F80"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPLuh9NKjjBBbIvkuPAKYD51v6LZq/zpPA
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZunKtgHTh_fL5crt4zdxx2lCEeY
Cc: 'Spencer Dawkins' <spencer@wonderhamster.org>
Subject: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 23:03:12 -0000
To the TRAM WG and RTCWEB WG and ADs: It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and encouraged to route quality demanding WebRTC media into their IP pipes that are capable of transporting real-time traffic without quality issues, using TURN servers. The subject from the TRAM mailing initiation spells out: *Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs* The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be used for the above purpose. (The objective of the TRAM WG milestone 3 is *not only* to resolve restrictive enterprise NAT/firewall traversal problem using TURN servers.) I request that this is explicitly clarified in the TRAM charter. The QoS discussions that has appeared in this TRAM WG, resulting from draft-martinsen-tram-discuss-00.txt and draft-thomson-tram-turn-bandwidth-00.txt has been confusing (to say the least), risking that the general QoS attitude within IETF work it is all about bandwidth and it will go away with time: (i) will *not allow* ISPs to use already available and currently deployable quality IP pipes for real-time traffic to also be used for WebRTC generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the very common and used method of simply providing an extra IP pipe (often provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by browsers. (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whatever bandwidth is available). Further explanations about QoS methods and their implementation were given a few days ago in: http://www.ietf.org/mail-archive/web/tram/current/msg00274.html (i), (ii) and (iii) risk *seriously delaying* usage of telepresence capable and quality demanding WebRTC (bandwidth being around 30 times higher over best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. I am therefore advising that draft-martinsen-tram-discuss-00.txt and draft-thomson-tram-turn-bandwidth-00.txt are withdrawn from TRAM. draft-martinsen-tram-discuss-00.txt can be reintroduced after clarification in the draft, that it is not about QoS as clarified by http://www.ietf.org/mail-archive/web/tram/current/msg00276.html. There are further details about this in the email http://www.ietf.org/mail-archive/web/tram/current/msg00303.html also copied below. It is therein explained that my repeated suggestion to RTCWEB WG http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html from the October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives of TRAM, immediately would allow: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now possible, for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), under *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks (PSTN, IMS) instead of the Internet (including OTT). The only activity required, is to call for ISPs review whether the traffic information transferred by RFC 5285 is sufficient for the needs of their networks. WebRTC *can be* used for existing application specific IP networks (such as IMS) for services existing on these networks, but with the introduction of the TRAM objectives above and the proposed traffic information in every RTP packet http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html as made possible by RFC 5285 available since 2008: (a) the same as well as other real-time services using IETF RTP traffic, *can also (often much better) be* implemented over the Internet (including OTT) (b) also considering needs of QoS, media routing, control, quality measurements, SLA implementation, usage, accounting, billing and SP-peering, that so far has been attributed application specific networks, but in practice and in reality have shown difficulties to implement (e.g. SPs peering of beyond POTS services, resulting in that the 50 year old, pre-AM radio quality telephony service, still is the only truly global communication service (and today often is used to initiate other better proprietary communication services). Application specific networks such as the IMS network have their own methods of handling QoS, that not in anyway will be made less efficient by the methods proposed here. Application specific networks *can use and will also benefit* from the flow control and traffic requirement marking of RTP streams proposed here. WebRTC *will be* used over the Internet (including OTT) and *will probably also be* used over the application specific IMS network for the services existing there through a gateway function from the Internet. With RFC 5285 QoS usage and with TRAM milestone 3 in place (which I suggest the WGs to expedite), market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. Who does not want a WebRTC-Ready Internet access? and Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes with much better QoE? and vice versa. The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether IETF standard work in these WGs by contributors having an interest in more than one of current or emerging: ISPs, carrier equipment vendors or web browser makers, may discriminate any with an interest only in one of these. The same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC 5285. One input for such review are responses directed to me in the September October discussion on the RTCWEB list and on the TRAM list from my entry there February 8 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html. Please see just sent emails: http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html http://www.ietf.org/mail-archive/web/tram/current/msg00303.html and further emails soon following this one, for details and history. /Karl Charter charter-ietf-tram-01 <https://datatracker.ietf.org/doc/charter-ietf-tram/> https://datatracker.ietf.org/doc/charter-ietf-tram/ Från: Karl Stahl [mailto:karl.stahl@intertex.se] Skickat: den 24 februari 2014 23:22 Till: 'Pal Martinsen (palmarti)'; 'tram@ietf.org'; 'rtcweb@ietf.org' Kopia: 'Oleg Moskalenko'; 'Alan Johnston'; 'Yoakum, John H (John)' Ämne: SV: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Hi Pål, You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html http://www.ietf.org/mail-archive/web/tram/current/msg00273.html whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC real-time traffic may flow. It seems to have been standardized already 2008 to allow such usage. QoS related step C) draft-martinsen-tram-discuss can then be taken out of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. I have repeated my suggestion to RTCWEB WG from the October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by any browser under any OS. Without step B), TRAM Enforcing the real-time traffic through the offered/discovered TURN servers, the real-time traffic may happen through the IP default gateways often congested by data traffic and QoS insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like Cable Networks and Mobile OTT. That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger data traffic and QoS insensitive streaming video and file sharing at no adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. I know a few of you Cisco guys are among the ones that have been fighting against the general it is all about bandwidth and it will go away with time-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but the pointers given in the current QoS discussion within TRAM: (i) will *not allow* ISPs to use already available and currently deployable quality IP pipes for real-time traffic to also be used for WebRTC generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the very common and used method of simply providing an extra IP pipe (often provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by browsers. (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whatever bandwidth is available). Further explanations about QoS methods and their implementation were given a few days ago in: http://www.ietf.org/mail-archive/web/tram/current/msg00274.html (i), (ii) and (iii) will *seriously delay* usage of telepresence capable and quality demanding WebRTC (bandwidth being around 30 times higher over best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. Below you are giving pointers saying They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. Those are unnecessary, risking leading to (i), (ii) and (iii) above. So are pointers such as: RMCAT where congestion avoidance for RTP is being developed. TRAMs Milestone 3 is for the purpose of directing real-time traffic where congestion control isnt already in place. Using RFC 5285 available since 2008, to fill traffic information in RTP packets (step D)) is probably a necessity for most future congestion control discussed. This chicken-and-egg circular also applies to RTCWEB direction of QoS issues to: http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos focusing on DSCP-mapping without even mentioning RFC 5285 available since 2008, to fill traffic information in RTP packets where it is a necessity and will allow: (1) applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM Milstone 3, to be used by *any network element implementing any suitable QoS methods for the particular network* for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), under *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks (PSTN, IMS) instead of using the Internet (including OTT). The only activity required, is to call for ISPs review whether the traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html <snip> two parameters (e.g. two bytes each) are encoded into the RTP header extension: A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence on a logarithmic scale. B) The quality characteristics for the stream, with the highest bit set to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to describe the stream. And with highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the individual bits. </snip> Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place, market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. Who does not want a WebRTC-Ready Internet access? and Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes with much better QoE? and vice versa. Please see further emails soon following this one, for details and history. /Karl Från: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com] Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Oleg Moskalenko; Alan Johnston; Karl Stahl; Yoakum, John H (John) Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Hi, I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on the wire format discussions. .-. Pål-Erik On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) < <mailto:yoakum@avaya.com> yoakum@avaya.com> wrote: +1 I fully agree with the comments that QOS should be a low priority for the initial focus of the TRAM efforts. There are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. Significant focus on QOS before we better enable TURN to be easily used in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < <mailto:alan.b.johnston@gmail.com> alan.b.johnston@gmail.com> wrote: Personally, I am not sure how much QoS is actually in scope for TRAM. Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - I'd concentrate on the TURN application-level functionality, for now, and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram
- [tram] Fwd: I-D Action: draft-thomson-tram-turn-b… Alan Johnston
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Alan Johnston
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Simon Perreault
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Simon Perreault
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Tirumaleswar Reddy (tireddy)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Pal Martinsen (palmarti)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Simon Perreault
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Tirumaleswar Reddy (tireddy)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Tirumaleswar Reddy (tireddy)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Karl Stahl
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Karl Stahl
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Alan Johnston
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Justin Uberti
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Yoakum, John H (John)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Michael Hammer
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Michael Hammer
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Karl Stahl
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Pal Martinsen (palmarti)
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Alan Johnston
- [tram] [RTCWEB] [TRAM] Protesting: Requesting TRA… Karl Stahl
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Pal Martinsen (palmarti)
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Karl Stahl
- [tram] A note from your (so far) friendly AD ... Spencer Dawkins
- Re: [tram] A note from your (so far) friendly AD … Justin Uberti
- Re: [tram] A note from your (so far) friendly AD … Mary Barnes
- Re: [tram] A note from your (so far) friendly AD … James Polk
- Re: [tram] A note from your (so far) friendly AD … Mary Barnes
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Cullen Jennings (fluffy)
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Barry Leiba
- Re: [tram] A note from your (so far) friendly AD … Gonzalo Camarillo
- [tram] BCP over TURN will not be in scope ... and… Spencer Dawkins
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] BCP over TURN will not be in scope ...… Cullen Jennings (fluffy)
- Re: [tram] BCP over TURN will not be in scope ...… Simon Perreault
- Re: [tram] BCP over TURN will not be in scope ...… Gonzalo Camarillo
- [tram] [rtcweb] The way to "Interfacing to QoS", … Karl Stahl
- Re: [tram] [rtcweb] The way to "Interfacing to Qo… Simon Perreault
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Karl Stahl
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Karl Stahl
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Gonzalo Camarillo
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Karl Stahl
- Re: [tram] [rtcweb] RTP header extension for "Int… Karl Stahl